Mac-Source 1994 July/Mac-Source_July_1994.iso/C and C++/Compilers⁄Interps/GCC-2.3.3r12/Build/Building GCC

Text File | 1993-04-15 | 5.5 KB | 115 lines | [TEXT/MPS ]

BUILDING MPW GCC

This document covers the basics of building and hacking on MPW GCC.

[It is also out-of-date.]

BISON

You need an up-to-date version of Bison, preferably 1.18 or later.  Bison is
probably available from wherever you got GCC, as well as from many other places.

[could include Bison with distribution, obviates need for it]

REBUILDING

To do a basic recompilation, first set the directory to the gcc distribution folder,
then type ":build:BuildOneStage 1".  This will create a new folder
Stage1-Mac68K, modify the necessary files, and create "first stage"
(compiled by MPW C) cpp, cc1, and driver tools, which can be put wherever you like.  The
process takes 10 years on a IIci.  The results are not quite as good as when
GCC compiles itself, but take a lot less time to produce and are fine for testing
changes.

To get the best versions, you have to use GCC to compile itself.  Three complete
compilations will be necessary, so do "BuildGCCStages 3".  On a IIci, it will run for
about two lifetimes.  If you say "BuildGCCStages 4" instead, then it will do one more
self-compilation; the fourth-stage compiler should be *completely* identical to the
third stage.  If not, then something is wrong.  In any case, the third stage cpp and
cc1 (in GCC.MPW.s3) are the ones to use (drop them anywhere on your command path).

BuildGCCStages needs lots of extra diskspace, about 7Mb/stage over and above
the 10Mb of the source distribution.  Actually, each stage only really needs
the tools built in the previous stage, not the object or temp files, so they
could be deleted to save space.

Another speedup is to use the "insn" target instead of "cc1" if only the machine
description "md" has been changed.  MPW makefiles have to do all the dependency
checking before starting execution, which means that they can't take advantage of
the fact that most of the insn-* files don't change when md is changed.  However,
if you make "insn" and then "cc1", the makefile will only have to recompile the
insn-* files that were actually changed by making "insn".

BUILDING GCC FOR 68000 and/or SANE

At present, one of GCC's unresolved bugs requires both -mc68020 and -mc68881 to be
turned on when compiling itself.  GCC is too slow to be particularly attractive on
older/slower Macs anyway, so this didn't seem like a real hardship. If you really
really need a 68000+SANE GCC, but don't care about having it be self-compiled, you
could build the first stage without -mc68020 and -mc68881 and use that; it is a little
slower, and some optimizations are missing, but otherwise works fine.

TESTING

This is an important step.  The folder Tests has a few programs that are small
enough to look at the assembly code, plus a version of dhrystone.  You should also
try using gC to build the programs in the MPW CExamples folder.  Of course, when
GCC successfully self-compiles, it is severely tested.  For test suites, we have
used the "C Torture Test" (available on various Internet servers) and the commercial
Plum-Hall test suite.

RETARGETING TO EXISTING MACHINES

*Not yet documented*

RETARGETING TO NEW MACHINES

The first thing to do is to study both the GCC manual where it describes how to
retarget, as well as existing machine descriptions, particularly for those machines
with which you are familiar.  Unfortunately, there is no really crystal-clear
description of retargeting anywhere.

The easiest approach is to find an existing machine description that is closest
to the one you're interested, build the compiler so you know it will compile and
run correctly, then gradually mutate the description until you're generating code
for your machine.  Many of the more mysterious macros in tm.h are extremely
difficult to write correctly, and if too many are changed all at once, it becomes
well-nigh impossible to discover the cause of a compiler abort.

GCC INTERNALS

GCC is unusually well-written and well-documented(not!), especially considering the size
and complexity of its intended task.  Nearly all of the machine-independent code
really is machine-independent, although its effectiveness falls off as one gets
further away from the VAX/68K/88K/Mips spectrum of machines and the Unix/Unix-lookalike
spectrum of operating systems.

The modifications that were made to get GCC to work under MPW fall into several
categories, each flagged by a distinct preprocessor symbol.

MPW is for those changes required by the MPW environment, independent of the compiler
used (typically #includes and file handling).  Most of these occur in contexts where
you'll also see USG (System V Unix), VMS, and MSDOS conditionals.

APPLE_C indicates those changes necessary to support Apple's dialect of C, such as
the pascal keyword and direct function definitions.  However, some changes to the
parser have not been so marked (since it gets run through bison).

MPW_C is for places in the GCC code that had to be changed to get the MPW C compiler
to handle them correctly.

APPLE_HAX is for generic changes that would be worthwhile for any version of GCC.
Some of these remove GCC's limitations with respect to the MPW environment, such as
the need to import variables for each function, and work in conjunction with
bits of the target machine description.

MPW_ASM is suppose to be hacks specific to generating MPW asm code, but this has not
been uniformly applied to the gcc source code yet.

TROUBLESHOOTING

There are two routines crucial to debugging - debug_dump_tree() is a one-argument
function that takes a tree structure and prints it on stderr, while debug_rtx()
does the same for rtl expressions.  These are especially useful to insert just
in front of a call to abort().